There are numerous areas where the need for distributing timing, both frequency and phase, across a backplane is manifested. One such area is described here by way of example.
Packet-based timing methods are becoming essential for delivering timing over packet-switched networks, often referred to as the cloud. In particular, Precision Timing Protocol (PTP) (aka IEEE 1588-2008) is becoming a defacto standard for delivering timing information (time/phase/frequency) from a Grand Master (GM) clock to slave clocks in end application-specific equipment; for example, where wireless base stations providing mobile telephony services require precise timing and the backhaul method of choice is Ethernet. The Grand Master clock provides timing information over the packet-switched network to the slave clocks by exchanging packets with embedded time-stamps related to the time-of-arrival and time-of-departure of the timing packets. The slave clock utilizes this information to align its time (and frequency) with the Grand master. The Grand Master is provided an external reference to serve as the basis for time and frequency. Most commonly this reference is derived from a Global Navigation Satellite System (GNSS) such as the GPS System that in turn is controlled by the US Department of Defense and its timing controlled very precisely and linked to the US Naval Observatory. Time alignment to the GPS clock is, for all practical purposes equivalent to time alignment to UTC.
The packet network between the network elements containing the master and slave clocks introduces timing impairments in the form of packet delay variation in each direction of transmission and, further, asymmetry in the transmission paths of the two directions both in terms of basic latency and delay variation. In order to mitigate the impact of packet delay variation in the network, it is common to utilize boundary clocks in some or all network elements between the master and the slave. A boundary clock can be simply depicted as in FIG. 1 which shows a network element 100 that implements the master side 135 on a different card (card-B 125) than the slave clock 130 that is implemented on card-A 120. The slave clock 130 derives timing from an upstream master clock using PTP messages exchanged over port-A 110 whereas the master clock 135 delivers timing to downstream slaves using PTP messages exchanged over port-B 115. It is necessary for the slave clock 130 to transfer time to the master clock 135 in an intra-network-element fashion depicted by 150.